OAuth Update: Adding the Client Credentials & Token Exchange Grant Types #882
Conversation
…for-oauth-client-credentials Add OAuth client credentials grant
…mplement-client-credentials-support Fix auth registration for client credentials
…mentation-of-client-credentials-flow Refactor auth helper methods
Fix failing tests and pyright
…eerror-in-pytest-test-case Fix OAuth tests using async fixtures
Fix resumption token update logic
Add OAuth token exchange support
…change-implementation-for-test-failures Fix token exchange metadata tests
Reported-by: sachabaniassad
Fix pyright case issues in tests and example
felixweinberger
requested review from
pcarleton
and removed request for
ochafik
felixweinberger
added
needs more eyes
There was a problem hiding this comment.
Hi @SoldierSacha thanks for this contribution! And apologies for the time it took to get back to this.
I checked with @pcarleton and it looks like this change is still pending SEP-1046: modelcontextprotocol/modelcontextprotocol#1047
I'm going to request changes for now as there will still be merge conflict resolution and potentially minor changes needed once that SEP is accepted.
…y-return-statements Refactor token handler helper flows
Thanks for the update, @felixweinberger! Understood — I’ll keep an eye on SEP-1046. Once that’s accepted and merged, I’ll rebase again and make any necessary adjustments. For now, I’ve gone ahead and updated this branch with the latest changes from Appreciate the review! |
|
Converting this to a draft for now as the SEP is still being discussed - once accepted feel free to re-publish for review. |
…-test-for-client-registration Allow additional grant types during client registration
Motivation and Context
#881
In addition to implementing the Client Credentials grant (as referenced in the issue linked above), I have also integrated support for the Token Exchange grant.
Reasoning for Token Exchange: While the Client Credentials grant is suitable for machine-to-machine authorization, I realized that there are times where the client machine (acting as an MCP Client) might have to make requests on behalf of an end-user to the MCP Server. With that being said, in the current implementation, this did not exist because there was no way to securely identify the end-user.
Now it does through Token Exchange.
How Has This Been Tested?
Added test cases (all pass), and also currently using in my own mcp server and client. Everything is working as intended.
Breaking Changes
None
Types of changes
Checklist
Additional context
No